\section{Lessons Learned and Discussion}
\label{section:lessons_learned}

The goal of this case study was to study the tractability of transformation
lifting for industrial-grade transformations. 
In this section, we reflect on the experience of lifting \gmtoautosar
and describe the lessons learned from it.

We note that applying \gmtoautosar to product lines fulfils a real
industrial need to migrate legacy product lines to a new format. This validates
the basic premise of our theory that lifting transformations for product lines
is an industrially relevant endeavour.
The observed results in Sec.~\ref{s:applying} indicate that using
\gmtoautosarlifted is tractable for industrial-sized product lines, even if some
additional optimization is required. It thus adds more evidence to the
evaluation results obtained using experimentation with random inputs
in~\cite{salay14}. This strengthens the claim that transformation lifting scales
to real-world models.

A claimed benefit of  transformation lifting is that transformations do not need
to be rewritten specifically for product lines.  
Instead, what is required is the lifting of the transformation engine. This case
study did not contradict this claim:
we were able to migrate legacy GM product lines to AUTOSAR without
having to rewrite the \gmtoautosar transformation for product lines. Instead, we
lifted the DSLTrans engine.

In \cite{salay14}, lifting was implemented using the Henshin graph
transformation engine~\cite{arendt10}. Specifically, we implemented lifting for
graph transformations while {\em using} some capabilities of Henshin (e.g.,
matching) as a black box.  However, lifting \gmtoautosar required {\em adapting}
part of the underlying transformation engine (DSLTrans) itself. The reason why
this was possible was because the  DSLTrans language is (a) based on
graph-rewriting and (b) uses graph rewriting productions as atomic
operations. It is thus possible to lift the entire engine by lifting
just these atomic operations while leaving the rest of the matching and
scheduling untouched.  On the other hand, since \gmtoautosar does not make use
of certain more advanced language constructs in DSLTrans (e.g., indirect links),
we were only required to make very targeted interventions to the DSLTrans
engine.  Lifting DSLTrans for arbitrary transformations will require more
extensive changes. For some language features, most notably, existential
matching, this also requires rethinking parts of the lifting algorithm
from~\cite{salay14}.




% Lesson learned: When is a transformation tool
% liftable?  Why did lifting work for DSLTrans? 
% And what would it mean if we were
% to do it to other tools?  At least some sufficient/necessary condition for
% liftability. E.g. for a rule-based tool, how should rules be done, how
% should matching be done in the transformation tool before it can be lifted.  The
% main reason DSLTrans is liftable is because the productions/individual
% applications are an atomic thing that we can go and just lift that and then the
% rest of the language can be adapted around that.
% 
% Another Lesson learned: In \cite{salay14} there was a particular
% shape in which the product line was kept.  This is not entirely  true about
% GM's product lines so something may need to be done (and that's a big deal).
% Maybe we will need to transform GM's product line to an annotative product line.
% Maybe the variability language used in GM is stronger than what we assume. We
% will have to describe (at least at a high level of abstraction) what it takes.
% 
% Lessons learned about the lifting process:
% \begin{enumerate}
% \item What does it take to lift a transformation tool?
% \item Confirmed or refuted  some of our scalability postulates (\cite{salay14})
% and applicability
% \item Confirmed or denied that the actual transformation stays exactly the same
% \item When is a transformation tool liftable?			
% \item Why did it work? And what would it mean if we were to do it to other
% tools?
% \end{enumerate}
% 		
% Lessons learned about the lifting outcome (the act of transforming GM's
% product line):
% \begin{enumerate}
% \item Effectiveness, applicability, scalability and the need to rewrite
% transformations that were done before (i.e., confirmation that you don't need to
% rewrite) 
% \item Confirmed or re-established the ideas that were done for much smaller
% models on sizes etc
% \end{enumerate}
% 
% 
% \mf{Comment on February 19: This laundry list is actually OK!}
% 

% 
% {Implications of the scheduling in DSLTrans:}
%  
%  \begin{itemize}
%    \item DSLTrans is an outplace transformation language. Because of that
%    presence conditions are only created in the output part of the model and not
%    over all the model, as described in the more general inplace case
%    in~\cite{salay14}. Still, presence conditions can accumulate over elements of
%    the output model which are linked to elements of the input model by backward
%    links. The reason for that is that those elements are part of the match of
%    the rule, and as such contribute to the adding of presence conditions to
%    other elements of the output model.
%    \item In the scheduling of the DSLTrans execution engine each rule executes
%    as many times as it can execute in one go, as all matches for the same rule
%    are found using one Prolog query. This is possible because of the fact that
%    rules in the same layer execute independently from each other, meaning they
%    don't read each other's output and execute in an independent fashion.
%    \item Because of the above, the accumulation of presence conditions during
%    the execution of a lifted DSLTrans transformation is much less problematic
%    that in the general case described in~\cite{salay14}. This is so because
%    elements in the output model generated by rules in the same layer only
%    accumulate the presence conditions generated by one execution of one rule,
%    given the each rule in the same layer executes independently from each other
%    and from itself.
%  \end{itemize}
